Transaction managers in enterprise systems may be used to monitor and manage transactions between resources and applications in application server systems. In particular, the transaction manager monitors global transactions and provides servers and resources within an application server system with status and availability information regarding other servers and resources.
The transaction manager may be provided by the application sever provided. One such provider of application servers is BEA Systems, of San Jose, California, who provide the Web Logic Server application server system. The WebLogic Server (WLS) Transaction Manager (TM) implements the J2EE JTA specification. This specification is based on the OpenGroup Distributed Transaction Processing Model (DTPM). A typical J2EE distributed transaction processing model 100 is depicted in FIG. 1. Distributed Transaction Processing Model 100 includes application (App) 110, resource manager (RM) 120, and transaction manager (TM) 130. The TM coordinates two-phase commit (2PC) transactions that involve multiple resources. Resources developed by third parties may be utilized in WLS applications because they adhere to the J2EE standards. The App communicates with the RM using an API such as JDBC (for relational databases) and JMS (for queuing systems). The App controls transaction demarcation using the JTA API. The TM communicates with the RM during 2PC processing using the extended architecture (XA) interface, specifically the XAResource interface as defined in the J2EE JTA specification. This interface provides methods for enlisting and delisting a resource in a global transaction, preparing the resource (first phase of 2PC), and committing or rolling back the resource (second phase of 2PC). There are also methods for use in failure recovery (recover), resource comparison (isSameRM) and error processing (forget).
Application components access an RM using the various APIs. These APIs typically utilize a logical connection to the resource. A logical resource connection is often associated with a XAResource instance. Enlistment of a resource in a global transaction entails having the TM associate the unique transaction identifier (Xid) with work that is performed in the resource, and is performed by invoking the XAResource.start( ) method on the resource. Subsequent application updates to the resource will be associated with the global transaction. Resource delistment entails having the TM invoke XAResource.end on the resource, which disassociates future application updates on the resource over the logical connection from the previously enlisted Xid.
FIG. 2 illustrates a typical resource enlistment process 200. In process 200, the App 110 first begins a global transaction at step 210. The App then accesses the resource and invokes an update operation on the resource at step 220 using an API specific to the resource. For instance, the App may perform a JDBC update operation. When the update operation is invoked on the resource, the resource first makes a call into the TM at step 230 using the Transaction.enlistResource method. The resource passes the TM the XAResource object that the TM needs to utilize in order to perform the transaction enlistment and 2PC processing when the transaction is later committed or rolled back. In response to the enlistResource call, the TM will invoke XAResource.start on the resource at step 240. The application update is then performed in the resource at step 250 and is associated with the transaction that was specified during the enlistment start method. After the application request has been processed, the resource may invoke the delistResource method on the TM at step 260 to disassociate future operations from the transaction. The TM responds by calling XAResource.end on the resource at step 270. The process 200 of resource enlistment is then complete.
While a first application has a logical connection with a resource, a second application may attempt to establish a logical connection with the same resource or attempt a concurrent update to the resource. In such a case, the second connection attempt would fail and result in an exception because to have different transactions simultaneously enlisted with a single logical connection is an XA protocol violation.
What is needed is a transaction manager that can manage multiple transaction requests from a resource object, thereby improving the efficiency of global transaction processing.